QRZ! Ham Radio 8

home *** CD-ROM | disk | FTP | other *** search

/ QRZ! Ham Radio 8 / QRZ Ham Radio Callsign Database - Volume 8.iso / pc / files / t_gtepms / gtepms.doc < prev next >

Wrap

Text File | 1996-06-25 | 75KB | 1,773 lines

The N2GTE Packet Message Switch (GTEPMS) v1.2 Documentation. ***************************************************************** Legal stuff: GTEPMS v1.2 is copyrighted by Doug Miller, N2GTE. PC-Node v3.59 is copyrighted by John Miller, G8BPQ. NET v890421.1 is copyrighted by Phil Karn, KA9Q. Enhancements to NET is copyrighted by Doug Miller, N2GTE. DESQview is copyrighted by Quarterdeck Office Systems. More Legal stuff: The suite of executables and support files are free to Amatuer Radio operations and is NOT authorized for commercial or military uses. A list of executables and support files that comprise the GTEPMS are listed in Appendix A. The GTEPMS must be copied and distributed to Amatuer Radio operators free of charge, except for reimbursement of out of pocket expenses. Plus, all files listed in Appendix A must be included and unaltered. N2GTE does not accept any liability for any loss; data, hardware, time or monies, through the use of the GTEPMS. ***************************************************************** Preface about these docs from the Author: The N2GTE Packet Message Switch is NOT for everyone, especially the beginner packeteer. The program and documentation herein and elsewhere assumes you already have a working understanding of DESQview, the G8BPQ Node software, TCP/IP, DOS and BBS operations in general. This documentation is not, nor does it claim to be, a tutorial on how to be a BBS SysOp using the GTEPMS. What IS covered in these docs is data needed to setup/operate the GTEPMS and included are items about other support programs (DESQview, BPQ and NET) that need either special configuation or have been modified to enhance the GTEPMS. You should already own docs for DESQview (they came with the program you bought) (what? you didn't buy it? Shame on you!!!) I recommend you read them carefully and keep them handy until you really get the feel for DESQview. There are extensive docs supplied with G8BPQ's node software and KA9Q's NET. These are not included in this documentation, but are supplied on disk for you. I also recommend you read those docs completely. I don't think I can over stress the importance of reading and comprehending all documentation supplied either with the commercial software you bought or what is supplied in this package. Many people have spend many hours writing and revising the words in these files to help make using the GTEPMS easier and fun to operate. You owe it to yourself and your BBS Users to understand what is contained here. There are places in these docs where certain items and procedures are "recommended". I define that word as meaning, "unless you have a VERY good reason to do otherwise, do it this way." ***************************************************************** Preface about the software from the Author: As can be seen by the hardware requirements, it takes a fairly capable computer to execute the programs efficiently. The software is not complicated, but is very complex. Several DESQview windows are working together to act as one complete system. Rather than running dupicate copies of the same BBS code in constantly open, static windows, the GTEPMS opens and closes parts of itself as needed, freeing system memory and clock time-slices. I have taken the major functional parts of a BBS system and divided them into logical groups of tasks, each being performed in its own DESQview window. This approach to the system has greatly increased its apparant speed to the User and other BBSs, and made the most effective use of your computer resources (memory, cpu time, etc). As you get comfortable with this system, you will get to know LISTER, RESOLVER and PORTER on a first-name basis. These are the only three GTEPMS windows which stay open all the time. The USER, FWD and MODEM windows are only opened when needed and closed immediately afterwards. (Exception, the NET window stays open all the time too, and although not specifically part of the GTEPMS, it is an important player if/when you have the GTEPMS cross between AX.25 and the TCP/IP worlds.) There are some files for you to edit and maintain thoughout the life-cycle of the GTEPMS. I recommend you use an ASCII Text editor that does not alter the structure of the file, nor insert special formating characters and spaces. ***************************************************************** Thanks from the Author: I wish to express my deepest thanks to the beta-testers who put up with the gliches, downtime, constant flow of upgrades and bug fixes. To those who help with the docs, and to those which said, "Gee, that's neat! But can you make it do this too?"; I thank you. WB3V Bill Howard KA3DXX George Stickler WA7NTF Gary Kohtala N3ETI Dick Wolters KA3RFE Ben "Pete" Hopping N3GIY Steve Moore WB3FFV Howard Leadmon WA3MEJ Jim Sears Also, thanks to Tom Clark, W3IWI, and Jim DeArras, WA4ONG, for moral support and suggestions. ***************************************************************** 1. Software Requirements: Two software packages are required to operate the N2GTE DESQview-Specific Multitasking Packet Message Switch (GTEPMS) software package; a third software package is recommended for those wishing to run TCP/IP concurrently with their N2GTE Packet Message Switch System. a. DESQview 2.01 or higher or DESQview 386 (which includes the QEMM 386 Extended Memory Manager for the 80386 Machines) is required. This is a commercial software package and must be bought by the SysOp/Owner of the system. Copywrites on DESQview and QEMM 386 are held by Quarterdeck Office Systems. b. The G8BPQ AX.25 Networking Software, version 3.57 (or v3.59), is free to duly licensed Amateur Radio Operators and is provided along with the N2GTE Packet Message Switch Software Package (on the same or separate diskettes). Note: G8BPQ v4.x and higher will NOT work due to major changes in BPQ interfacing. Thus the only versions to use are v3.57 and v3.59. c. (optional) The N2GTE version of NET v890421.1.5N2GTE TCP/IP and interfaces with G8BPQ's AX.25 Networking Software is recommended if you plan to run your TCP/IP system concurrently with the GTEPMS and use the same radios and TNC's. The TCP/IP files necessary to run N2GTE's modified version of NET and documentation are provided with N2GTE's Packet Message Switch; however, for documentation on TCP/IP in general, you should get one of the later versions of KA9Q's Internet Protocol Software package with documentation (available from many sources). Strongly recommend 128K of ramdrive. You may use VDISK or any other ramdisk utility you wish. If you choose not to use a ram drive, you still must supply a valid drive letter in the file \CONFIG.GTE (see later about this file). The PMS uses the ram drive to spool temporary files during inter-window communications. ***************************************************************** 2. GTEPMS Hardware Requirements: Minimum Equipment for Full Operations (with full BBS, Node, and TCP/IP Operations) to run then N2GTE Packet Message Switch code is as follows: - An 80286-class IBM-Compatible Machine with at least two megabytes of EEMS or LIM 4.0) RAM is required; or a 80386 with two to four megabytes of RAM (4Mb would be best.) - One or more KISS-Mode TNC-2 TNC's (or an internal HDLC card with onboard TNC's) that will run with the G8BPQ AX.25 Net- working Software. ***************************************************************** 3. Set up your directories and files on your hard drive: The GTEPMS expects to find all its file in the root directory of its default disk drive. For those which not NOT wish to actually use a "real" root, you can place all GTE files in a subdirectory and use the DOS SUBST command to substitute the subdirectory with a drive letter. See your DOS manuals on how to do this. The author has used a substituted drive letter T: for his system; so for here on after the default root drive:\path will be refered to as T:\ (which is actually C:\GTE). The following example can be placed in your \AUTOEXEC.BAT file: SUBST T: C:\GTE (or whatever you call the directory) This will create a T:\ drive for the N2GTE Program files to operate from. Of course, you may use a "real" root drive. Note: You may have to place "LASTDRIVE=Z" statement in your \CONFIG.SYS file to allow DOS to use drive letters that high. Whichever method you use, you should set up the following subdirectories on your "root GTEPMS Drive": \HELP \LOG \MSG \PATHS \QUEUE \RSR \USER (there is a small batch file packaged along with the system which can make these directories for you. It is called MAKEDIR.BAT) If you plan to run the TCP/IP package, you must also create these directories: \SPOOL \SPOOL\MAIL \SPOOL\MQUEUE \SPOOL\RQUEUE (there is a small batch file packaged along with the NET code which can make these directories for you. It is called MAKEDIR.BAT) Copy all the main N2GTE Packet Message Switch System and associated executable and command files to your GTEPMS root directory (whatever drive designator you give it). Copy all the G?-PIF.DVP files to your DESQview directory and use the DESQview "Add Program" menu selection to add them to DESQview's main menu. a. Bring up DESQview. b. Select Open a Window and the Add a Program option. c. Select Other Programs from the Add a Program Menu and mark all of the G?-PIF.DVP files to be added to the Open options. d. Hit return to install them. The PIF files come made to use substituded drive T:\. If you have chosen not to use the letter T, you must then edit all the PIF files for the GTEPMS to state the drive you wish to use. Thus to keep things simple, and standardize from system to system, the author recommends you follow his advice and use substituded drive T:\. Edit the ASCII files according to the detailed information following: \CONFIG.GTE File - This file sets several functions and variables within the GTEPMS environment. sample \CONFIG.GTE file: BBSCALL=N2GTE BBSADDR=MD.USA.NOAM BBSQTH=Ft Meade BBSZIP=20755 RAMDRIVE=F TCPIP=YES BBSALIAS=FMBBS DVPATH=C:\DV BPQPATH=C:\BPQ359 QUIET=23-03 ENFORCEQUIET=YES PASSME=YES BIDCHECK=YES note: if you do NOT run the TCP/IP package, mark the TCPIP variable as NO. With TCPIP=YES, then re-queued mail from NET (in the \spool\rqueue) will be picked up by FWD.EXE. Mail can also be converted back to SMTP. With TCPIP=NO, the BBS will ignore anything to do with IP. Notes: With QUIET hours set, this means that your GTEPMS BBS will NOT forward bulletins during this time frame (SB type bulletins will NOT be forwarded during these times; however, Bulletins sent to SP SYSOP are "personal" mail and WILL be for- warded). SP and ST type mail will FWD during QUIET hours. With ENFORCEQUIET set to Y or y your BBS will "enforce" the quiet hours by disconnecting ANY BBS that "attempts" to forward a bulletin to you during your established "quiet" hours. As soon as the GTEPMS station senses the SB command, it will disconnect the station attempting to forward the bulletin. In setting the ENFORCEQUIET, you may enter YES or Yes or Y or y; or NO or No or N or n, but the code only reads the first character, so it doesn't really matter. ----------------------------------------------------------------- \FWD. - you will have to edit this file to conform to your forwarding needs. Here are some notes on the Forwarding File: The \FWD. file entries consist of at least two fields. The first is the ultimate destination (be it callsign, partial callsigns, or H-addr entries). Separated from the first field by any type of whitespace (spaces or tabs) is the second field. This consists of the callsign of the bbs you will send the mail to get it on its way to the final destination. If you wish to export the mail to a file, simply place the filename in the second field. (filenames must have full drive:\path\filename.ext designators because GTEPMS uses the second character being a ":" to detect it is to go to a file instead of a bbs. Hopefully the FCC will never issue a callsign with a ":" in it.) Sample lines from a \FWD. File: K3AKK N4QQ -- this forwards all mail for K3AKK to N4QQ; this type of entry may be an individual user call or a PBBS station call or may be a TNC MBOX call. GB7* N4QQ -- this forwards all GB7xxx mail to N4QQ. HB9* W3IWI -- this forwards all HB9xxx mail to W3IWI. 0* W3IWI -- this type entry sends NTS TFC to a specified BBS call by ZIP (wildcards are allowed) (in this case the BBS station is W3IWI). NTSCA KD3O -- this type entry sends NTS traffic to a specified BBS call by STATE ZIP DIGRAPH (in this case the BBS is KD3O). .AZ KD3O -- this type entry sends Packet Mail for stations in Arizona to KD3O for further forwarding. .AUS W3IWI -- The GTEPMS code can also key on these type designators and route the mail for them to a specific long-haul forwarding BBS's. KA3DXX C:\NODE\DXXMAIL.TXT -- this entry exports the mail to a file. N2GTE (SMTP) -- this entry converts and queues the mail to be sent SMTP over your TCP/IP links if you are running the IP package. If the entry is for your own call, your mail will be sent directly to you BM mailbox file. .CA N4QQ W3IWI WA7NTF -- this entry will queue up anything for California for those three BBSs. Whichever BBS successfully gets the mail first will kill it so the others will not get it. note: The \FWD. file is for SP and ST type mail ONLY. Bulletins are handled completely separate from mail. Also note, the H-addr routings must begin with a "." to denote they belong to the H-addr and is not the bbs callsign. Note: RESOLVER uses a "first hit - bailout" search algorythm. W3IWI will get 209xx zips, but W3KDC will get all other 20xxx zips in the example below. 209* W3IWI 20* W3KDC Another example: WA4ONG will get the Zips while W3IWI will get the stuff for overseas. 4X* W3IWI 4Z* W3IWI 4* WA4ONG ----------------------------------------------------------------- \CHORE.xx Files - these files will have to be edited to suit your forwarding needs. To import files, list them in the CHORE files so that the FWD window picks them up. Filenames are recognized by having a ":" in the second character place. The following are examples of a \CHORE.xx file: D:\SPREAD.OUT D:\REQDIR.OUT D:\REQMUF.OUT WB3V KA3DXX KD3O KB8AOB N3DMC The *.OUT files could be output files created by a server. You may have as many chore files as you need. The author names his chores by the minute he FWDs. example: CHORE.10, CHORE.40 and CHORE.55 Each chore file can be different, thus you would FWD to a different group of BBSs during that particular FWDing cycle. ----------------------------------------------------------------- \PORTER.CNF - this is the file that sets up the forwarding times that PORTER will open a FWD window. The SysOp can also use it to have PORTER open other windows at certain times during the hour. These other windows could be batch files to run servers or other things. The file consists of four fields; <type> <minute> <pif file> <parameter> Normally there is only one type; "T" (for Timed function). All other type are reserved for future enhancements. The second field is the minute after the hour you wish this window to open. The third is the filename of the DESQview PIF file which opens the window. The last field is any parameters you may wish to pass to the window when it opens. Sample PORTER.CNF File: T 05 C:\DV\SB-PIF.DVP T 10 C:\DV\GF-PIF.DVP CHORE.10 T 40 C:\DV\GF-PIF.DVP CHORE.40 T 55 C:\DV\GF-PIF.DVP CHORE.55 Note: In this example the line beginning with T are "timed" chores for the BBS. T, of course, denotes "Timed function". The 05, 10, 40, and 55 are the times in minutes past the hour for the chores to take place. The SB-PIF.DVP file is for a server. The GF-PIF.DVP (called at :10,:40,:55 minutes past the hour) are forwarding chores for the FWDing window. Note: Try to avoid assigning chores for timed functions at :00, :15, :30, or :45 minutes past the hour, since these times are the times RESOLVER will task PORTER to beacon the "unresolved" mail, thus at these exact moments, the BBS is fairly busy building the mail beacon. Note: Remember, PORTER has a max limit of 16 timed chores, so watch how many things you task PORTER to do. ----------------------------------------------------------------- \DV-MAIL.DAT File - This file is the message database and should not be tampered. Repeat -- Leave it alone! ----------------------------------------------------------------- \BIDOK. - this file should be okay as is, but you may need to add any local area distribution lists that may have NON-STANDARD BID's. (BID is Bulletin ID [that funny $ thing on the end]) When the BBS receives a bulletin, it checks its BID against one it formulates itself from the last header line. Normal BIDs are of msg#_callsign type format. If the BID that came along with the bulletin fails this check, it is placed on hold until it either grows stale and expires or the sysop manually goes in and release/kills it. But many bulletins do not follow the msg#_callsign format on purpose. Examples are ARRL and AMSAT buls. These have special BID formats that always begin with certain letters. The BBS has a feature that if a bulletin fails the BID check, the BBS checks the BIDOK file before placing the bul on hold. This BIDOK file consists of the @BBS designated followed by at least one whitespace (tab or space), then the beginnings of the odd BID to try to match. If the odd BID is only 3 characters long, then only the first three characters of the bulletin BID is checked for a match. If the odd BID is four characters long, then four characters of the bul BID is checked, etc, etc.. Stars and questions marks CANNOT be used as wildcards. If the first characters of the bul BID matches the odd BID, then the BBS releases the bulletin normally (if it is not already stale). The SysOp may edit the BIDOK file to add new NON-STANDARD BID forms to the file. The following example is a good start for the BIDOK file: AMSAT ANS AMSAT ORB ARRL ARL USA RACESBUL USA RTDX USA SPC SKYWRN NWS Note: The GTEPMS will automatically accept BIDs with the following formats: msg#_callsign callsign_msg# msg#callsign and the Europe style of BIDs which encodes in the Date. ----------------------------------------------------------------- \HADDR. - this is a file the GTEPMS will create from message headers. The HADDR file is updated by the HEADX.EXE program as it extracts header information from incoming messages. The file has entries like the following: KA5EJX.#WTX.TX.USA.NA [Lubbock] Z:79413 WG5F.#WTX.TX.USA.NA [Midland] AE5I.#WTX.TX.USA.NA AA5KG.#WTX.TX.USA.NA [San Angelo] Z:76901 WA6RDH.#NOCAL.CA.USA.NA [Dixon] Z:95620 This is one of the files the BBS checks for Hierarchical information when it resolves a message for forwarding. Note: you must run HEADX.EXE yourself from a DOS window. I recommend running it about once every two days, or so, depending on how many new message your system receives per day. HEADX.EXE must be ran from the BBS-root directory and perferablly while all activity is quiet (ie no new messages in the process of coming in). ----------------------------------------------------------------- \LINKS. - this file will describe the Area names of the files directories and the paths to them as shown in the following example ASCII G: TCPIP Y:\TCPIP NETDOCS C:\DOCS NOSDOCS C:\DOCS\NOS GTEDOCS C:\DOCS\GTE SERVERDOCS G:\REQDOCS HELPFILES T:\HELP BBS-BY-STATE E:\HADDR To use the LINKS file, create a file in the "root" directory of the PMS called \LINKS. Enter the contents in two columns -- the first column is the alias you want for the direc- tory AREA; the second column is the drive:\path(s) for the real directory. Do NOT include a trailing backslash. What this file does is "link" these drive:\paths into a psuedo directory for your users to upload and download ascii file to/from. The user will only be able to use directories that you have linked into your system. They cannot use sub-directories of the links unless you have also linked them in with separate link names. (See the above example in lines NETDOCS, NOSDOCS and GTEDOCS.) ----------------------------------------------------------------- \MOD. - this file contains the Message of the Day and you should edit it to suit your needs or desires. You should keep it kind of short for the most part, but on certain occasions you might have reason to include a short announcement of some specific event or suggestion to read a given message. The SysOp can enter something like "Read Message #12450 for Important Notice" or something along those lines. Edits to the \MOD. file take effect immediately and the changes will be seen the next time a user (or bbs) connects. ----------------------------------------------------------------- \MOUNT. - you will use this file to enter the BPQ-Node Station Calls-SSID's to tell PORTER which other GTEPMS stations it can inter-link with for Remote Service Requests (RSR). An example of a \MOUNT. file: N2GTE-6 WA7NTF-7 N3ETI-5 WB3V-2 Remember, this is the callsign of the BPQ node, not the BBS itself. Remote Service Requests (RSR) is what make GTEPMS systems unique. If your system cannot resolve a certain piece of mail, it can, thru the RSR, task other GTEPMS system to assist. You virtually have access and use of their \FWD., \HADDR., \USER\*. files to help your system resolve mail. Once you ask (and get an answer) your system "learns" and can resolve this mail again in the future without help. Thus, a new GTEPMS can start with a very minimal \FWD. file and actually learn and grow if there are other GTEPMS within netrom range. ----------------------------------------------------------------- \SEQUENCE.SEQ -- this is the file that maintains your one-up message numbering for your BBS. On bootup the BBS reads the file, but then never reads it again; only writes to it. The only purpose of the \SEQUENCE.SEQ file is for message number recovery during re-start of the BBS. The BBS keeps track of sequence numbers, but continually updates that file so the data in the file stays in sync with the count inside the BBS. The only way to "force" a warp jump to another number would be to close the BBS (using the shutdown procedures listed in the setup section); change the number in the \SEQUENCE.SEQ; then start the BBS back up. ----------------------------------------------------------------- \SPAWN. - you may create this to suit your needs to spawn other non-BBS windows upon boot-up. If you want to open another DESQview window as soon as the BBS System is booted up, you need to put the xx-PIF.DVP files in the SPAWN file. CAUTION: DO NOT UNDER ANY CIRCUMSTANCES PUT PORTER (GP- PIF.DVP) OR RESOLVER (GR-PIF.DVP) IN SPAWN -- THESE TWO FILES ARE OPENED BY LISTER (GL-PIF.DVP) WHEN IT COMES ON LINE. Here's an example SPAWN file: C:\DV\IP-PIF.DVP C:\DV\BD-PIF.DVP where IP-PIF.DVP and BD-PIF.DVP are the DESQview PIF files that will open the windows for N2GTE's version of NET TCP/IP window and a "Big DOS" Window. ----------------------------------------------------------------- \SWAP. - This file swaps out the BBS call or alias and in the process strips off the state/province digraph, coun- try, and continent codes, as well as the @BBS call for all mail destined for the BBS. Example SWAP File: KA3DXX SEVBBS WA7SSO W3YA <-- this is handy if someone has changed calls K1LNJ WB3V.MD.USA <-- or upgraded like Bill did. NTSMDC NTSMD <-- to correct misconceptions ARL ARRL <-- to standardize incoming ARRL bulletins. ARLB ARRL ARLP ARRL ARLS ARRL USABBS USA <-- to standardize incoming USA bulletins. ALLBBS USA ALLUS USA ALLUSA USA WA7NTF.WA.USA WA7NTF.MD.USA <- he moved. You may place H-addr info in the second field of the swap. ----------------------------------------------------------------- \BULLETIN. File: Each bulletin distribution list must have its own line within this file (such as, ARRL, AMSAT, BSA, CBBS, EU, MBLBBS, MDCBBS, REBBS, RLIBBS, SKYWRN, USA, etc.). Each of these lines would contain the station calls that are to receive the bulletins. Exporting bulletins to files is supported, enter the full drive:\path\filename.ext in the file. Its format is: <designator> <callsign> <callsign> <callsign> <etc> example: MDCBBS WB3V KA3DXX WA7NTF N4QQ WA3ZNW WA3MEJ AACO WB3V KA3DXX WA7NTF N3ETI KA3RFE ARRL WB3V KA3DXX WA7NTF N4QQ WA3ZNW USA WB3V KA3DXX WA7NTF N4QQ NEWHDR WB3V D:\NEWHDR.TXT KA3DXX SKYWRN WB3V Notice (in NEWHDR) how files may be used also. ***************************************************************** (2) Text Files in the GTEPMS Subdirectories and Associated Directories: a. \HELP Directory Files: The help files are okay, as is, except for one; the \HELP\INFO. file. You will need to edit it placing your own station information. Standard help file are included in the GTEPMS package. They are contained in the file HELPFILE.ZIP which should be unzipped in the \HELP directory. Notes: You may add any additional files you wish with one-letter or one-number filenames as long as you DO NOT USE THOSE LETTERS ALREADY SET ASIDE FOR BBS USE. You may omit your additional single-letter or single- number files from the master \HELP\HELP. file, if you wish, since they do not have to be listed there for you to access them. This could be a way to create personal "cheat-sheet" file for your own use as SysOp and not advertise there existance to the world. This directory contains or will contain all the help files. Except for HELP and INFO, each of the single-letter files contains the help file for that particular BBS command and is invoked by the ?x command (where x is the single-letter command for which help is needed). The command "I" will display the \HELP\INFO. file, which contains Station INFOrmation prepared by the station's SysOp. The command ? by itself will display the \HELP\HELP. file, which gives a quick overview of the various commands. ----------------------------------------------------------------- c. \PATHS Directory Files: Files in the \PATHS directory are station callsigns (without SSIDs) and contain the connect commands to get your BBS to the other BBS stations you forward to. This directory contains the files with the connect paths to the stations with which the BBS connects to conduct forwarding. Filenames within the directory are the station callsigns of receiving stations without any regional suffixes (.MD.NA.USA, etc.) or SSID's (-4, etc.). The files contain ONLY the connect commands and the calls necessary to make the actual connection to the BBS or MAILBOX station getting the mail. No other information should be included in the PATH files, unless you want to specify forwarding times. \PATHS Files - BBS Calls: (1). Here is an example connect path from KA3DXX to N2GTE, which share a common frequency and may work direct or via NetRom compatible nodes: Filename: N2GTE C FMBBS (2). Here is an example connect path to W3IWI, which do not share a common frequency, but which may forward via NetRom compatible nodes. C DCA6 C DCA1 C W3IWI (3). Part Time or Limited forwarding: In GTEPMS, you may now specify a starting and ending time to forward to a station if you do not want to forward full time. (ie HF FWDing) To do so, you put the following in the specific callsign file in the PATHS directory: #05-17 <-------- Start/end hours. First entry in file. C DCA1 <-------- The rest of a normal connect script. C KA3XYZ (4). Special NOS and NET handling. Some BBS codes, particularly NOS and NET, require the connectee to issue a <CR> after connection before the BBS will function. If you need to FWD to such a system, the last line in your \PATHS\*. file will be (NOS). This tells the FWD window to send a bare carrage return after successful connection to the station. Here's an example: C FGGM C APLIP C WA3WZA (NOS) (5). Special Scripts. If your path must follow odd routes (such as going thru K-Nodes), you will probably need to use a special script to control what you send and what you expect to receive as the response. The use a special script, the first line in the PATHS files for that particular BBS must be (SCRIPT) and yes, include the parens and must be all caps. The second line is the filename of the script to use. Thus a special script for BBS WA3XXX would have a PATHS file looking like this: (SCRIPT) C:\EXTRA\PATHS\WA3XXX.SCR Now, within the file C:\EXTRA\PATHS\WA3XXX.SCR is the script for the BBS to follow. Initially the BBS will connect itself to the BPQ switch, so the special script should start from just after that point. There are two basic type of script lines, "." and "~". The line beginning with the PERIOD is what you send; the line beginning with the TILDE is what you wait for as a response. The file should end after you get the final response you expect (in this case "Connect to WA3XXX"). The BBS will then start waiting for the other BBSs SID, welcome message and finally its first ">" prompt. While waiting for an expected response, there is a timer ticking. If an unexpected response is RXed, it is ignored and the timer keeps ticking. At timeout, the BBS will disconnect and continue with the rest of its chores. Here is an example script. (Remember you are already connected to the BPQ switch). .C DCA ~ to .C VANODE ~ to .X RIC220 ~###LINK MADE .C WA3XXX ~ to Note: Maybe you can not see them, but there ARE spaces in front of and behind the "to" in the TILDE lines. SPACEs and upper/lowercase _IS_ significant. The response phrase starts from the first chars immediately after the "~" and continues to the end of the line. All spaces will be part of the string the BBS will use to match the responses. ----------------------------------------------------------------- d. \USER Directory Files: The files in the \USER directory use callsigns (without SSID's) as filenames; new user files and are created as a new user connects into the system. The BBS creates the user file and sets the user level at 0 for guest user; however, when a BBS connects, it is set as a BBS automagically based on informa- tion the two BBS's exchange. The SysOp can create a user file or change the status of a user by editing an existing user file. example user file \USER\WA3XXX. 3 <- user level 1 <- number of connects 15153 <- message number of last message listed "Sam>W3IWI" <- user's name & Home BBS "9010191610" <- user's latest login time In the above example, the ">" tells the code where the name stops and where the HOME BBS Call begins. This is transparaent to all windows. If you ever edit these file, remember the quotations and puncuation is important. User levels are as follows: 0 - guest; 1 - user; 2 - expert; 3 - BBS; 4 - SysOp. -1 - Excluded. <- the author was coersed into adding this feature. Quirk: When starting the GTEPMS for the first time and when you open the CONSOLE window, you will notice that you do NOT have SysOp priviledges. Close the CONSOLE window and open a DOS window. Change to the \USER directory and you will find there a file with your callsign. Edit the first line of that file to be a 4. Save the file. You are now set to be a SysOp of your own system. ----------------------------------------------------------------- e. Other GTEPMS Directories: (1). MSG Directory: This directory contains the mail files. The mail filenames are the message numbers of the mail messages and contain the message text within them. ----------------------------------------------------------------- (2). QUEUE Directory: The BBS uses this directory to "queue up" messages for forwarding to other BBS or Mailbox stations. The filenames contained in the directory are callsigns and the contents of the files are the various message numbers that are "queued up" for that station callsign. The extention of the files key to what type of message is queued. (ie WA3ZNW.P is an SP message) ----------------------------------------------------------------- (3). RSR directory: The PMS code creates and deletes files in this directory to handle the Remote Service Requests (RSR) orginated or received by the BBS. PORTER handles the RSR's in both directions and makes the connects from one GTEPMS station to annother. PORTER also tasks RESOLVER (and LISTER, if necessary) to fulfill RSR's from another station. ----------------------------------------------------------------- f. Your BPQCFG.TXT file: You will need to edit the BPQCFG.TXT file to conform to the needs of the GTEPMS system. If you are already running the G8BPQ AX.25 Networking Software, all you will need to do is make the pertinent changes in the file; the TNCPORTS sections, and the APPLICATIONS section. You will have to rerun your BPQCFG.EXE to create the new BPQCFG.BIN file that BPQCODE accesses on bootup of the system to set up the node. Specific TNCPORTS must be defined in the TNCPORT section of the BPQCFG.TXT file to allow the GTEPMS Code to work with the G8BPQ code. The maximum number of TNCPORT Definitions in the BPQCFG.TXT file is still sixteen; however, you should keep your TNCPORTS to be used by BPQ above COM 4, since you may have other peripherals, such as a mouse or an internal MODEM and other SERIAL port connections, that use COM ports 1 through 4. If you do NOT use COM 1 through COM 4 for anything else in your comput- er, feel free to use them in the BPQCFG.TXT for APPLMASK=1 ports. IMPORTANT: ALL ports defined in your BPQCFG.TXT must have an appropriate APPLMASK=<number> parameter. Even if you have read the BPQ docs and know that if this is left out it defaults to APPLMASK=1. INCLUDE IT ANYWAY! When PORTER comes alive, it reads you BPQCFG.TXT file to see which ports you have set aside for BBS use. It keys in on the phrase "APPLMASK=1". If it senses a commport that does not have an APPLMASK statement, PORTER will ignore this port (and it will tell you so as it boots). In this case PORTER is warning you of an error in your BPQCFG.TXT file. Any connect made to a port that PORTER is ignoring will result in just that, "a connect". And nothing else will happen. No BBS, no welcome, nothing. There are two type of ports GTEPMS will use: a normal emulated TNC, and one emulated PK232/UFQ port. First decide on the maximum number of user/fwd windows you wish to have open at one time. I recommend no more than 4 or 5. Allocate those ports and normal TNC ports. Next choose a tnc port to emulate the PK232/UFQ tnc. This will be the RSR port. Also ensure the RSR APPLMASK is set to the proper application listed in the APPLICATIONS= statement at the end of your BPQCFG.TXT file. Read the BPQ docs for more info on how and why these things must be done. The following type changes/additions should be made in the BPQCFG.TXT File: Sample TNCPORTS: ; TNCPORT COM=5 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS APPLMASK=1 ENDPORT ; TNCPORT COM=6 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS APPLMASK=1 ENDPORT ; TNCPORT COM=7 ; USED BY PORTER.EXE TO MANAGE PORT ASSIGNMENTS APPLMASK=1 ENDPORT ; TNCPORT COM=14 TYPE=PK232/UFQ ; hardwired to the Remote Service Requests APPLMASK=8 ; function. ENDPORT ; ; Applications for GTEPMS: APPLICATIONS=BBS,*HOST,*SYSOP,*RSR ;add the *RSR (yes, the star in front of RSR is manditory.) ***************************************************************** 6. To Open the BBS: a. To open the BBS manually, enter ALT, O, GL, to open the LISTER window (GL-PIF.DVP). b. To open the BBS on boot up, create a DESQview bootup script (DESQview.DVS) to open JUST the LISTER window. Here's how to do it from a text file. Enter the following text with your your favorite text editor: {Learn ! "!startup"} {DESQ}OGL {Finish} That's all there is to the file. Make sure this is all your text file contains. This will boot up LISTER.EXE and LISTER.EXE will open RESOLVER.EXE and PORTER.EXE, and then will open any other windows you have designated in your SPAWN file. Then run the DESQview Convert a Script program (without DESQview booted up -- the filename is CONVSCR.EXE); when the menu comes up select T to convert a Text File to a Script File, enter your text file filename and the name of the DESQview file -- that should ALWAYS be DESQVIEW.DVS for the DESQview bootup script. Once you do that, boot up your system, and watch LISTER do its thing. After you boot up LISTER, go on with your setup. c. Whether the SysOp manually brings the BBS on line or uses the GL-PIF.DVP file in a DESQVIEW.DVS script to bring it up at system boot up, LISTER itself will spawn open the RESOLVER and PORTER windows (in that order). d. If you don't like the way the windows are arranged, you may use DESQview Resize and Move Options, to rearrange LISTER and RESOLVER so that they only take up a little less than half of the screen. You can either put them on the bottom or at the top or in the two right hand or left hand quadrants of the screen. It's up to you how you want to see them on your screen. e. Some of the windows you might want to bring up as full screen. The G?-PIF.DVP files provided with the BBS software may have the positions diffent than what is indicated here or the way you want them to appear. Rearrange them to suit your own tastes, BUT DO NOT CHANGE THE EXTENDED FUNCTIONS options, since they are more or less HARDWIRED into the multitasking programming. Also, DO NOT CHANGE THE RAM requirements in the G?-PIF.DVP file, since N2GTE has already optimized them. Most of the programs require about 80Kb, but some use more and some use less. You should leave them as N2GTE has set them, so you will have enough RAM and will not waste any. ***************************************************************** 7. To Close the BBS Gracefully: a. First, check for activity. Do an ALT S to see the Open Windows. DESQview will show what windows are active. If no windows other than 1, 2, AND 3 (LISTER, RESOLVER, PORTER) and your regular windows you have SPAWNed are open, close your spawned windows, then continue on to step b. You may have Users logged in or a BBS FWDing. Unless it is an emergency, be kind to your Users and wait for them to disconnect before continuing shut-down. If you continue on with step b while people or connect, they will get disconnected. b. Select the PORTER Window (Window 3). This will UNHIDE the window. Next, press the ESCAPE key -- this will close the PORTER Window. c. Select the LISTER window and in all capital letters type the word ABORT, then press Enter or Return. You will need to be in the lefthand column for this to work properly. Closing LISTER this way will also close RESOLVER and shut down the BBS.. ***************************************************************** 8. The N2GTE Console Window: a. To Open the Window: Press ALT, then O, then select GC, and press Enter or Return. This will open the Console Window. The Console Window is for the SysOp to use locally, so he/she may read mail or bulletins, kill mail/bulletins, or post mail or bulletins, either to local users or to be forwarded. The SysOp may also use mail messages to send requests to servers. The SysOp CAN NOT make CONNECTS to the NODE or other stations from the CONSOLE window. Use a terminal program of your choice that is compatible with the BBS. b. To Close the GTE Console Window, enter B (for Bye), and press Enter or Return. ***************************************************************** 9. GTERM Window: a. BPQCFG.TXT Notes for GTERM Version 2.01 (GTERM21.EXE): This version is hardwired for COM=11 with APPLMASK=2; it IS a HOST Mode application. b. General Notes: (1). The GT-PIF.DVP file is contained in the GTERM.ZIP file along with this short documentation file. (2). N2GTE does not recommend any changes to the DV window sizes, since the program owns two windows -- an input window and an output window. Function Key F2 will adjust the size of the input window. There are four fixed sizes and press- ing F2 will rotate through the window sizes in a "round robin" fashion. (3). Pressing Function Key F6 gets you help. (4). This version DOES NOT support YAPP although it says it does. (5). The ASCII capture file is hardwired to "\CAP- TURE.TXT" of whatever drive you have defaulted this application to. If it is in your C:\ root directory, that is where CAP- TURE.TXT will be -- it doesn't matter that you might have the file in a directory called GTEPROGS\UTILS off D:\ drive -- the path to CAPTURE.TXT will be C:\CAPTURE.TXT. ***************************************************************** Section II - System Operation: 1. N2GTE Packet Message Switch Program Files - Executable Program Files Associated with the GTEPMS: ----------------------------------------------------------------- USER.EXE: This file interfaces the users with the BBS portion of the system. On users entering their own calls as their home BBS -- well, beginning with Prototype Version 0.4 of the N2GTE code, USER.EXE will not allow this to happen. If the user insists he is a BBS, then he will be prompted to send a message to the SysOp for further negotiations. ----------------------------------------------------------------- PORTER.EXE: This file does the necessary "porting" functions of the Packet Message Switch and opens all the user and forwarding windows. As its name implies, PORTER manages ports and porting. It has its own configuration file (PORTER.CNF), for the timed functions it manages, along with the other porting functions. The T command assigns the times for PORTER to execute the "timed" CHORE.xx files. PORTER, in turn, assigns forwarding chores to available TNCPORTS configured in the BPQCFG.TXT. Timed Batch files do not have to have TNCPORT as- signments, but are handled in the same way as FWDing chores are. Servers: You could build a batch file to run every hour that actually executes your servers. To have the BBS call it every hour, add a "T Command" line in your PORTER.CNF. Make sure you pick a time that would not conflict with your FWDing time or during "beaconing time". We do not want the FWD window to try to read files that the servers may be trying to create, all at the same time. An example PORTER.CNF line to do this would be as follows: T 05 C:\DV\SB-PIF.DVP F:\DBASE.DAT The "05" means five after the hour. Next is the directory path to the filename NOT OF THE BATCH FILE, BUT of the DESQview PIF File (SB-PIF.DVP, for the SERVER.BAT Script) that runs the batch file window. Last is an argument, or parameter you wish to pass to the batch file. ----------------------------------------------------------------- CONS.EXE: The SysOp Console program file. This is the file that manages the SysOp's CONSole window. The SysOp uses this window to do all the SysOp duties and can read mail or bulletins, post mail or bulletins, read the help files (if necessary) or other things, but the SysOp CAN NOT use the CONSole window to make connects to other stations. ----------------------------------------------------------------- FWD.EXE: Does the forwarding; uses the FWD. file to do the forwarding. This is the executable file that PORTER.EXE calls to perform the forwarding chores. You import files to the BBS and export files from the BBS. You place the filename(s) you wish to import in the "chore" files. Please ensure the second character is a colon. Remember the BBS keys on that to know it is a file you are talking about. You export to servers from the FWD. file and import from servers in the CHORE.* files. Multiple forwarding windows are supported, but only one should be started at a given time and they should be spaced apart in time by about five minutes, at least. The reason this is necessary is that message files could be corrupted by the interaciton of windows, since the _mailGaTE_ will also be accessing files and if two forward windows are going at exactly the same time, some corruption of files could easily result. Most of the time there won't be any problems, but a word to the wise should be sufficent -- why take chances? The FWD. file contains the forwarding information (based on who gets the mail for whom or what. See the sample FWD. File for examples. If you make changes in your FWD. file in your GTEPMS root drive, you need to copy the new file over to your virtual ram drive, which you set in the CONFIG.GTE file. How to Force a Forward: a. Open the Forward Window (GF). b. The window will display FWD.EXE on a line by itself. c. The SysOp will then MANUALLY enter the CHORE.## filename that he/she wants to be execute (i.e., CHORE.10), then the SysOp will press <Enter>. That forces the forward cycle. ----------------------------------------------------------------- LISTER.EXE: LISTER lists things and mangages temporary spool files. One major function that LISTER performs on BOOTUP of the BBS is to open the RESOLVER.EXE and PORTER.EXE windows. LISTER.EXE may be opened by the DESQview STARTUP file (DESQview.DVS) or manually by the SysOp. Additionally, LISTER.EXE may also open other windows with the SPAWN file (see SPAWN). Typing "ABORT" (without quotes) in the LISTER window closes RESOLVER and LISTER and cleans up files (especially the DV-MAIL.DAT). All activity should be quiet and the PORTER window should already closed (by hitting the <ESC> key while the PORTER window is top-most in the window stack). ----------------------------------------------------------------- RESOLVER.EXE: This one handles the mail, traffic, and bulletins. Its main goal is to get rid of messages. RESOLVER's main job is to get rid of mail, so it uses the HADDR file to add the HIERARCHICAL addressing suffixes and the FWD. file to determine where to send the messages then hands them off to PORTER, which opens the windows for forwarding at the forwarding CHORE times. RESOLVER bounces mail back to LISTER, so LISTER can try to get the User's HOME BBS and attach it to the address. If LISTER does not have the User's HOME BBS it will take no further action, but, if it does, it tacks the @BBScall onto the message and sends the mail back to RESOLVER to try again. If a user enters any @BBS call in the @BBS field of a message that will cause RESOLVER to override what is in the USER database that RESOLVER checks for HOME BBS's. RESOLVER also initiates Remote Service Requests (RSR) through PORTER to other GTEPMS stations (see MOUNT file). ----------------------------------------------------------------- HEADX.EXE: This file scans the Message Headers and pulls in information on new BBS stations, then it updates the HADDR file, a Hierarchical Address (HADDR) file and creates the HEADERS.IMG File - Don't mess with this file! It is an image file that HEADX.EXE uses. HADDR is a working file that RESOLVER uses to check for header information when it needs information as it "resolves" messages and prepares them for forwarding. The SysOp should run HEADX.EXE once every week (or every two to three days on heavily used BBS's -- depends on the volume of traffic through the BBS). HEADX.EXE pulls header information from messages the BBS receives and adds new information to the HADDR file. When the messages are resolved for destination and there is no call in the @BBS field, then RESOLVER tasks LISTER to check for and supply the HOME BBS of the User (if known); LISTER will check for the call in the USERS directory and if it has the call will pass it back to RESOLVER, which then continues to resolve the message based on the HOME BBS. If HOME BBS is not known, either by LISTER or by RESOLVER, the message should stay on the BBS. If it IS known, then RESOLVER will queue it up for proper forwarding to another BBS station with the call and the Hierarchical addressing information added "automagically". HEADX must be run by the sysop about once every two to three days. It MUST be called from your root GTEPMS drive, so you must be sure the change to the root drive is made or HEADX won't be able to do its job. Also see HADDR information. ----------------------------------------------------------------- MODEM.EXE: The MODEM.EXE code is now divorced from USER.EXE. MODEM.EXE will auto-detect baud rates (300 to 9600) There is a callsign validation on log-in (only amateur calls accepted). MODEM.EXE will can echo the user's type back to them. It also sends <CR><LF> pairs. It comes with its own GM- PIF.DVP. MODEM.EXE uses the initialization file MODEM.INI. This file contains at least three lines: a) the COMM port of your modem; b) the maximum baud rate your modem can use c) AT commands to configure your modem. Example: 1 2400 AT E0 X4 Q0 &D2 S2=64 AT S0=1 The PORTER window accepts the commands "MODEM ON" and "MODEM OFF". When you type MODEM OFF, PORTER then ig- nores any modem state changes. This is handy for you to use another modem program in another window temporarily. When fin- ished, close the external modem program and type MODEM ON in the PORTER window. PORTER will then try to reconfigure the modem back to \MODEM.INI's setting. ** Be advised ** Some modem programs leave the modem in a terrible state when they exit! PORTER can not recover the modem parameters. If this happens, you must reboot. You MUST use some sort of COMxBIOS not only to buffer RXed characters, but to also support other hardware handshaking INT14 calls. Also be advised, modem programs do not generally support "shared interrupts" very well. A word to the wise here should be sufficient. Your modem MUST be able to support DTR signals. This means your modem must hang-up and enter command state when the DTR signal is transistioned from high to low (or TRUE to FALSE). Usually this is a software switch you set in MODEM.INI (AT &D2). In some external modems, it is a switch setting on the modem itself. N2GTE also advises, for your modem/bbs security that you change the ESCAPE char of your modem to something other than the well-known "+". Choose whatever character you like, but remember what it is so you can still you it manually (as in other programs like SLIPNET.EXE). You can change the ESCAPE char by placing in your MODEM.INI file the command "AT S2={ascii}" where {ascii} is the ascii value of your newly chosen ESCAPE char. ----------------------------------------------------------------- Here is a short doc on how to set up your system to fwd via your modem. 1. In PORTER.CNF make another timed event entry using GZ-PIF.DVP and the file CHORE.MDM. Mine looks like this: T 20 C:\DV\GZ-PIF.DVP CHORE.MDM 2. In CHORE.MDM you put the callsigns of the stations you want to fwd to just as you do in your CHORE.10, CHORE.40, etc. files. 3. In your T:\PATHS directory you want a .MDM file for each station that you will fwd to via modem. For instance, in testing this code I used N2GTE.MDM. In this file you will have the following lines: SPEED PHONE NUMBER PRECEDED BY THE LETTER 'T' (tone) or 'P' (pulse) CONNECTION SCRIPT (see in other places in this Doc about scripts) For example, my modem fwding file for N2GTE.MDM looks like this: 1200 T672-3959 (the dash is not necessary) ~: (the "enter your callsign" line ends with a colon) .N3ETI NOTE ON SCRIPTS: If you were calling an AA4RE TELINK board or any other board that requires a password, your script could look like this: 2400 T672-3959 ~call .N3ETI ~pass .GUEST ----------------------------------------------------------------- GTERM21.EXE: A DESQview-specific Terminal Program to provide the SysOp with communications to other stations. This program currently DOES NOT have YAPP Binary Transfer support and is primarily for the SysOp to connect to other BBS stations or nodes. There is a separate documentation file (GTERM.DOC) for this program; GTERM21.EXE can be run without the BBS being up, if necessary, although the BPQCODE must be running. ***************************************************************** 2. Command Summary - User Commands: B - Bye D - Download (ASCII files) Syntax: D AREA FILENAME.EXT H - Help I - Info J - Journal (list of users and BBS's connected since system bootup) K <msg#> - Kill this message KM - Kill Mine that I have already read KT <msg#> - Kill Traffic L - List (all since last list) L <nr> - List from nr (a 50-range limit is imposed.) L <nr1> <nr2> - List between nr1 and nr2 (a 50-range limit is imposed.) LL <nr> - List Last <nr> of msgs LT - List all Traffic L@ <bul> - List At <bulletin designator or callsign> L< <callsign> - List from callsign L> <callsign> - List to callsign LM - List Mine (whether read or not) LN - List Mine (only new and unread msgs) N <name> - Update Name in User database. NH <Call> - Update Home BBS Call in User database. O - Over to the node (not available from MODEM). Q (or QS) - Query status of msg database. QL - Query Links QU - Query all users in the USER database QU <callsign> - Query User QQ - Query the QUEUE directory R <msg#> - Read msg# (can have up to eight on a line.) RM - Read Mine (whether new or not). RN - Read Mine, but only those I have not read yet. SP - Send Personal Message. SB - Send Bulletin Message. ST - Send NTS Traffic Message. S - (will be converted to SP) S ALL - (anything to ALL will be converted to SB) T - Talk to the SysOp U - Upload ASCII file Syntax: U AREA FILENAME.EXT V - Same as R but displays all the gory headers too. W - What areas are available. W area - What files are in that area. X - Toggle UserType eXpert to normal. The following commands are availble on the modem port only: SET ECHO - either ON or OFF SET PAGE - either ON or OFF @ - make me a SuperUser (will be password challanged) X - crossconnect me with the BPQ node (SuperUsers only) FTP - switch MODEM in an FTP Server for SLIP sessions. ***************************************************************** 3. Command Summary - SysOp Commands/Console Macros/Etc.: Extra Commands available from the CONSOLE window: E <msg> - Allows the SysOp to edit certain field of a message. F <msg> - forces RESOLVER to re-resolve that message. K- - Clean up the DV-MAIL.DAT LK - List Killed LH - List Held LX - List expired LU - List unresolved msg (personal and traffic only, bulletins are always supposed to resolve) L-<days> - List all msgs older than days. No spaces. L?<status> - List all msg with this status. L?<type><status> - List this type of messages with this status. MT msg# filename - to copy just the text of msg# into filename. MM msg# filename - makes filename out of what you would normal see during a normal READ command. MV msg# filename - makes filename out of what you would normal see during a normal VERBOSE command. (all headers included) RH - Release Held bulletins (see end of Docs) RS - Release Stale Held only RB - Release BadBID Held only RU - Review and edit NonResolved mail ~r filename - to insert a prepared file into the message text. This will read filename.ext into the message. ------------------------------------------------------- Commands Available from the keyboard in a USER or MODEM window: F10 Key - Go into "chat mode" on user window. When a user uses their "T" command to get the SysOp's attention and the SysOp decides to be available, he/she switches to the user window and presses the F10 Key. To end a "chat mode" session all the SysOp has to do is enter F10 again. ***************************************************************** 4. File/Directory Ownership: a. Because this BBS is not only multi-connect, but multi- tasking also, file access conflicts can become a problem. To help keep things on the up-and-up, certain BBS windows "own" certain files and/or directories. If another window wants info from a resource it does not own, it must request the info from the owner, NOT go get it on its own. b. The following is a list of file/directories and their respective owners: File/Dir.: Owner (comments): DV-MAIL.DAT LISTER (read/write/create) \USER\*. LISTER (read/write/create) SEQUENCE.SEQ LISTER (read/write/create) SPAWN. LISTER (read only, during start-up) SWAP. RESOLVER (read only) FWD. RESOLVER (read only, copies to ramdisk for quicker searches) BIDOK. RESOLVER (read only) BULLETIN. RESOLVER (read only) \QUEUE\*. RESOLVER (read/write/create/destory) HEADERS.IMG HEADX (read/write/create) HADDR. HEADX (write/create), RESOLVER (read only) \LOG\*. RESOLVER (write/create) MOD. USER,MODEM (read only) MOUNT. PORTER (read only during RSRs) \HELP\*. USER,MODEM (read only) \PATHS\*. FWD (read only) \MSG\*. USER,FWD (read/write/create); LISTER (read only/destory) CONFIG.GTE ALL (read only) CHORE.* FWD (read only) PORTER.CNF PORTER (read only, during start-up) GR-PIF.DVP LISTER (read only, during start-up) GP-PIF.DVP LISTER (read only, during start-up) **-PIF.DVP PORTER (read only during a winodw opening) ***************************************************************** Section III - TCP/IP Support for GTEPMS/G8BPQ's TheNode: 1. There can only be one TELNET<->BBS pipe at a time. Second sessions to socket 30 will receive a busy notice. TELNET is handled by N2GTE's version of NET. It interfaces to BPQ thru TNC port COM=8. When a session is started, it tells BPQ to connect COM8 to any available BBS port (COM5 or COM6 or whatever you have setup). The BBS has no idea whatsoever that the connect was via telnet. The TCP/IP user will issue a connect using the following syntax: telnet n2gte 30 The IP user will be prompted for a callsign, then if there are any USER ports available, the first available one will pop up and the BBS itself will treat the connect as a normal AX.25 connect. 2. The following BPQCFG.TXT TNC Port Scripts deal directly with the TCP/IP interfacing with the BBS and the Node: a. The GTEPMS TELNET Port to Socket 30 via the Node allows TCP/IP Stations to make TELNET connections to the AX.25 BBS/Mailbox. TCP/IP TELNET sessions to the BBS are tied to Socket 30 AND to the node's COM 8. TNCPORT COM=8 APPLMASK=2 ENDPORT b. This is the first port defined in the AUTOEXEC.NET file as one of your radio ports and corresponds to it. In this case it just happens to be a UHF port and is given the device name "uhf" in the attach line of the AUTOEXEC.NET file. The device name "uhf" is arbitrary. TNCPORT COM=9 TYPE=KISS KISSMASK=1 ENDPORT TNCPORT COM=10 TYPE=KISS KISSMASK=2 ENDPORT c. This is the second port defined in the AUTOEXEC.NET file and corresponds to it. This one just happens to be a 2M port and is given the device name "vhf" in the attach line of the AUTOEX- EC.NET file. The device name "vhf" is arbitrary. ***************************************************************** 4. Information for the AUTOEXEC.NET File: a. Attaching the Shared Ports: attach asy 0 8 ax25 uhf 1024 230 4800 attach asy 0 9 ax25 vhf 1024 230 4800 the above lines equate to two radio ports, defined as PORTNUM=1 and PORTNUM=2 (441.000, 147.570 respectively) and equate to the BPQCFG.TXT TNCPORT's COM=9 and COM=10, respectively. Note: The "asy 0" refers to the G8BPQ Node Software or "io addr 0". If you run more than two ports, they will also have to be "attached" in like manner and the number in AUTOEXEC.NET will always be one less than the port number in BPQCFG.TXT. b. Starting the protocol that allows the TELNET sessions to the BBS: start bbs This is the protocol added by N2GTE, which allows "telnet" connects to the BBS from TCP/IP stations. Telnet ses- sions to the BBS are made to socket 30 (syntax: telnet n2gte 30) and the user will get the messages "SYN sent", "Established", then a prompt for your callsign. After you enter your call, you will get the notice "Ok" from the node. Next, you will be connected to the BBS, unless all the BBS ports are busy. After you are through, you may issue a disconnect with the "b" command or issue an "O" command to go to the Node before disconnecting. c. To have the _mailGaTE_ functions of the BBS working the correct way, one must add the following lines to your autoexec.net file. What these lines actually do is covered on the NET docs. smtp gateway <yourhostname> #<-- for _mailGaTE_ smtp mode queue #<-- for _mailGaTE_ d. Remember, true hostnames are required for SMTP to work properly, so ensure that your HOSTS.NET is arranged properly. The proper placement in the HOSTS.NET file is as follows: IP.IP.IP.IP hostname alias alias alias alias... #comments where the "IP" denotes the digits of the IP Address. The first name after the IP is supposed to be the hostname of whatever the other operator calls his host. For Example: 44.0.60.34 ka3dxx.ampr.org ka3dxx # George Stickler ***************************************************************** Section IV - GTEPMS Features and Special Notes from the Author: 1. N2GTE Comments on Multiple Forward Windows a. Practical experience has shown me that about three connects per freq is max that one station can handle at 1200 baud. If multiFWD were used, the SysOp MUST ensure they use different freqs; i.e. force Lv2 connections with designated ports (C 1 SEVBBS-1, C 2 W3IWI, C 3 NATCAP-1, etc). This would spread out the freq loading. This would be a SysOp responsibility. Can you imagine what 441.000 would be like if N2GTE FWDed to KA3DXX, WB3V, WA7NTF, and N4QQ at the same time? b. MultiFWD may not be the best uses of computer resources. Every TNC set aside by BPQ needs about 2 to 3K memory. That's not too bad and can be considered insignificant part of a 4Mb RAM pool. But the FWD window needs about 100K. Allocating about 400K of the approximate two to four Mbytes you have available for new windows IS a significant chunk. If a system is "gang FWDing" there could be little memory left for user windows. The SysOp should decide which is more important; FWD useless bulletins or servicing his loyal Users? c. Not only is memory required, but consider the time slice allocation also. That is something most people forget. They remember RAM and freq loading, but what about uP loading. This factor does not exist in non-multitasking system. Many people think about RAM-hogs and disk-hogs, but us multi-taskers must also consider the time-hogs (or things that may degrade perform- ance). In DESQview, each window is given a slice of uP time. What that window does with it is up to the window. If there is nothing to do, it should give the remaining mseconds back to DV so DV can immediately switch to another window. All DV-friendly programs do this. ALL GTE programs do this also. In fact, LISTER and RESOLVER are truely DV-specific programs and actually STOP executing until DESQview wakes them up with something to do. SO while idle, LISTER and RESOLVER do not even get their time slice handed to them. ALL other windows have something to do with the COM ports (PORTER, USER and FWD). Thus they can not go to sleep. Each time DV gives them a time-slice, they make a quick check for incoming characters. If none are waiting, they give up the remainder of their time. But as long as there are characters coming in (or going out during FWDing) those windows want all the uP time DV will give them. It has to be that way. You only get one shot at pulling a character out of the comm ports. Once you miss a character, it is gone forever, because the TNC (or DRSI) has already sent its ACK saying it RXed all ok. It did. The program simply failed to suck the data out of the buffer before overflow. This will probably never happen on a 386@16MHz or above, but must be considered from a programmer's standpoint. That is the only reason I mention it here. d. As I coded it , a FWD window will sense that another FWD using the same chore file and will immediately shut down. I did that on purpose. If a long FWDing session takes over an hour to complete, there has to be a hook to keep another window from trying to FWD to the same stations next cycle. e. With multiFWD, the SysOp has the ability to be in a constant (or near constant) state of FWDing. This could give one the reputation of being a channel hog. f. The USER window will REVerseForWarD to a BBS, thus actually changing itself to a psuedo-FWD window upon the "F>" command. With that consideration in mind, does one really need so many other FWD windows open at once? Every USER window has the potential of being a FWDing window, depending on the type of connection. 2. Lifetimes for Bulletins, Mail, and NTS Traffic: a. Personal Mail (SP type) and NTS Traffic (ST type) NEVER goes stale. It would remain for years if the sysop lets it. b. The following data applies ONLY to bulletins: - Bulletins received from other BBS's that arrive at an N2GTEPMS System are immediately marked as stale if they are over 14 days old. - A bulletin created locally will be marked as stale once it has aged over 14 days. - Stale bulletins older than 14 days (whether created locally or received from another BBS) are marked as killed. c. Killed Messages (whether SB, SP, or ST) are deleted from the system about 3 days after they were killed. d. These times are hardwired into the code and are life- spans recommended by W3IWI. These lifespan time frames will always remain hardwired in the BBS code of the N2GTEPMS System to assist the SysOp in keeping stuff too old to be useful out of the network. If a particular SysOp has a beef about that, then N2GTE recommends the SysOp choose another BBS code to run. 3. The Remote Service Request (RSR) Feature: The RSR feature will let one GTEPMS system poll another one in an attempt to "resolve" mail. This feature in a given GTEPMS System will automagically interact with other GTEPMS stations so that they will have the ability to share one another's Message Switch files. If LISTER and RESOLVER on one system can't figure it out, they will check with another GTEPMS station to resolve problem mail. RSR is built-in. The RSR is one of the main "selling" features of the Message Switch System; its ablility to share another system's resources. 4. Associated with MODEM.EXE are two environment variables the user can set. They are ECHO and PAGE. To turn them on, the user would type "SET ECHO ON" or "SET PAGE ON" (without quotes, of course). Turning them off should be intuitive. Typing "SET" by itself will display the current environment. All new modem uses have both defaulted to ON. What ECHO does should be self-explainitory. PAGE will allow only about 20 lines of text to flow, then it will stop until the user send a <CR> to continue, or an "A" (must be capitol) to ABORT the current action. 5. LOG's: The BBS now Logs into a directory off of the BBS root called \LOG - All logs will end up there. They are updated every 15 minutes, so be advised not to have them open in to viewer/word processor during "BEACONING" time. 6. FWDing is done, ST first, then SP, then SB. All queues are FIFO. 7. You should create a file called \PASSWD. It should contain one line of text. Case of the letter WILL matter when responding to a password challenge. You will be challenge when your own call connects to the BBS or when giving the SuperUser command "@" in MODEM. If the PASSWD file does not exists, then there will be no challenge. The challenge is in the form of the BBS sending you five numbers. These number represent random position within the line of text in the PASSWD file. You must respond correctly with the appropriate charaters or get disconnected. Example: BBS sends -> 5 26 32 2 50 Your respond with -> Tw.hq (note puncuation characters are also valid) Note: Your own callsign will not be challenge if you have place in your CONFIG.GTE file the variable PASSME=NO. 8. From the MODEM, a user can gain access to the BPQ switch. First the user must become a SuperUser by issuing the "@" command. The after passing the password challenge, he issues an "X" command (for "Xlink"). He will then be connected to the BPQ node and may do statuses and node listing; even further connect out the node. ***************************************************************** Late updates. The \STOPBULL. file -- Due to recent FCC action, N2GTE has added a feature to RESOLVER which will allow SysOps to automatically place selected bulletin distributions on HOLD. These held bulletins can NOT be FWDed, nor even viewed by Users. The SysOp must manually release these bulletins. The STOPBULL file simply contains a list of @BBS designators of what bulletins are to be held. To release these, the SysOp (from the console window) types RH (Release Held). He/she will then get to view each bulletin in-turn and decide on its fate. To release STALE bulletins, you must now use RS (Release Stale) and for BADBIDs (RB). My personal STOPBULL contains this: USA STOPBULL only works on Bulletins, SP and ST mail are NOT effected. ***************************************************************** Late Late Update -- To make the above STOPBULL feature more flexable, I have added a new variable to the CONFIG.GTE file. It is called STOPBULL=x, where x is a bit-significant value to control how the \STOPBULL. file will be used. Here is how it is broken down: STOPBULL bit# 2 1 0 | | \- Hold bulls ORGINATING at my BBS. | \-------- Hold bulls FWDed to my BBS. \---------------- Hold SB, SP and ST to/from a certain call. Thus: STOPBULL=0 will cause no action. STOPBULL=1 will stop only bulls in \STOPBULL. that ORIGINATE from your BBS. STOPBULL=2 will stop only bulls in \STOPBULL. FWDed to your BBS. STOPBULL=3 will stop both ORG and FWDed. STOPBULL=4 will stop only SB, SP and ST TO/FROM callsigns listed in \STOPBULL. STOPBULL=7 will do it all. Example: The \STOPBULL. file has this: USA WA3QNS and the CONFIG.GTE has STOPBULL=5 Thus all @USA orginating from my BBS will be held, plus all mail, be it any @BULL, or SP/ST, to/from WA3QNS will be held. I, N2GTE, DO NOT LIKE HAVING THIS FEATURE. IT GRATES AGAINST MY FEELINGS. But, I have included it to allow the SysOp more control over what goes out of his transmitter. ************************************************************************ APPENDIX A List of Files from the GTEPMS System GTE12.ZIP CONS.EXE DV-MAIL.DAT FWD.EXE FWDMOD.EXE GTERM21.EXE HADDR HEADERS.IMG HEADX.EXE LISTER.EXE MAKEDIR.BAT MODEM.EXE PORTER.EXE RESOLVER.EXE SERVNET.EXE USER.EXE HELPFILE.ZIP @ B D E F FTP HELP I INFO J K L M N O Q R S SET T U V W X READ.ME MDMBIOS.ZIP GTE1BIOS.COM GTE2BIOS.COM GTE3BIOS.COM GTE4BIOS.COM DV-PIF.ZIP GC-PIF.DVP GF-PIF.DVP GL-PIF.DVP GM-PIF.DVP GP-PIF.DVP GR-PIF.DVP GT-PIF.DVP GU-PIF.DVP GZ-PIF.DVP SAMPLES.ZIP BIDOK BULLETIN CHORE.10 CHORE.MDM CONFIG.GTE FWD LINKS MOD MOUNT PASSWD PORTER.CNF SPAWN STOPBULL SWAP BPQ359.ZIP 220KISS APPLS.DOC BPQCFG.EXE BPQCFG.TXT BPQCODE.EXE BPQDUMP.COM BPQDUMP.DOC BPQNODES.COM BPQNODES.DOC CHANGES.BPQ COMMANDS.DOC CONFIG.DOC DRSI.CFG HOSTMODE.DOC INT14.DOC JKISS JKISSCW.DOC JKISSP KISS KISS.CFG KISS.DOC KISSMODE.DOC NODEDRV.COM NOSBPQ.DOC PAC2.COM PAC2.DOC PASSWORD.BPQ PATCHID.COM QUAD.CFG SAMPLE.C SWITCH.DOC SYSOP.COM SYSOP.DOC WISHLIST GTE-NET.ZIP ALIAS AUTOEXEC.NET BM.EXE BM.RC FTPUSERS HOSTS.NET IP-PIF.DVP MAKENET.BAT NET.EXE NET-DOCS.ZIP ADVANCE.DOC APPEND1.DOC APPEND2.DOC APPEND3.DOC BM.DOC COMMANDS.DOC NETROM.DOC README.DOC SETUP.DOC TCPIP.DOC TESTDRV.DOC END OF APPENDIX A List of Files from the GTEPMS System ************************************************************************